Method and system for key certification

ABSTRACT

A method and system for key certification in a public key infrastructure. The infrastructure has a network formed of a plurality of nodes. Each node has a private and public key pair. The nodes are either or both a certifying node and a certified node. A certifying node provides a digital certificate referring to the public key of a certified node. The digital certificate is signed by the private key of the certifying node. The method includes providing a root public key for a user, the root public key being at a any node in the network chosen by the user, and providing a chain of digital certificates from the node with the root public key across the node network to any other node.

FIELD OF THE INVENTION

[0001] The invention relates to a method and system for keycertification. In particular, the invention relates to key certificationin the field of public key cryptography.

BACKGROUND OF THE INVENTION

[0002] Public key cryptosystems use a pair of asymmetric related keys,one for encryption and the other for decryption. Encryption in thiscontext does not necessarily imply that the result is confidential,since data encrypted with a private key can be decrypted by anyoneholding the public key—which may be widely available. One of the keypair, the private key, is kept secret by the user, while the other key,the public key, can be publicly disclosed. The key pair must have theproperty that, given knowledge of the public key, it is infeasible todetermine the private key.

[0003] A user receives or, with suitable hardware or software, cangenerate for itself a pair of keys which are generally two largenumbers. The user keeps one of these keys private and never disclosesit. The other can be safely made public, just like a phone number orsimilar personal data. Due to the way the keys are generated,information encrypted with the private key can only be decrypted withthe public key and vice versa. Using a key pair means that the senderand receiver do not need to share a secret key.

[0004] Public keys do not have to be published to the world. They can beshared as widely or narrowly as business and privacy requirementsdictate.

[0005] The term “user” is defined as any entity including individuals,groups of individuals, one or more individuals in a role, corporations,organisations, computer applications or systems, automated machines,etc.

[0006] Public key cryptography makes the following possible:

[0007] Anyone knowing the user's public key—can send the user a messageencrypted with that key and can be sure that only the user—who alone hasthe corresponding private key can decrypt it. This providesconfidentiality.

[0008] The user might also encrypt a message with his private key. Thiscannot provide confidentiality, because anyone who knows thecorresponding public key can decrypt it. But the fact that they candecrypt it means the message must have come from the user—who alone hasthe private key. This provides authentication and can also be used as abasis for non-repudiation—the digital equivalent of a signature.

[0009] If a sender signs a message with his own private key and thenencrypts it with the recipient's public key, confidentiality,authentication and non-repudiation are provided together.

[0010] In practice, things are actually more complex. In the firstsituation, for performance and operational reasons, the sender willchoose a random symmetric session key and a symmetric cipher to encryptthe message. The public key will be used to encrypt just the sessionkey.

[0011] In the second situation above, a message is signed with a privatekey and this is known as a digital signature. One problem with signaturemethods is that cryptography can be slow due to the processing andcommunications overheads required. The volume of data sent can be morethan double the size of the original message.

[0012] Confidentiality may not be required and it may be desirable to beable to send signed plaintext messages. A method can be used that doesnot require the entire message to be encrypted and therefore reducesprocessing and communication overheads. This method is based onobtaining a “digest” of the message the user wishes to sign. One form ofobtaining a message digest is a hash function. A hash function is aone-way function which maps an arbitrarily long piece of plain text intoa comparatively small fixed-length bit string which is the messagedigest.

[0013] The hash function has the property that if the message is changedin anyway an entirely different value of message digest is produced bythe hash function. It should also not be possible to generate twomessages that have the same message digest. Given P (plaintext) itshould be easy to compute H(P) (hash of the plaintext). Given H(P) itshould be effectively impossible to find P (the original plaintext).

[0014] In the second situation, the hash function is used to generate amessage digest from the content of the message to be signed. The messagedigest is then encrypted using the private key of a key pair to obtainthe signature. The original plaintext message is transmitted togetherwith the signature.

[0015] A recipient of the message uses the same hash function to obtaina digest of the plaintext message that has been received. The recipientalso decrypts the signature using the public key of the key pair andobtains the message digest which was sent by the originator. Therecipient compares the two digests and if they are the same, thesignature is verified and the recipient is assured of the integrity andauthenticity of the message.

[0016] For public key encryption to be effective, a user must keep hisprivate key secret. For example, this could be done by apassword-protected smart card. In a traditional public keyinfrastructure, the user also needs a certificate for his public key.This certificate tells those the user deals with that the public keyreally does identify the user. The public key certificate is issued by areputable agency, such as a bank.

[0017] A problem arises if the user is dealing with a business associatewho does not know the bank issuing the certificate certifying the publickey of the user. The bank itself can have a public key certificate,issued by a suitable umbrella organisation. That umbrella organisationtoo can have a public key certificate. This can result in a chain ofcertificates leading to a point (referred to as the root) which thebusiness associate does know. The hierarchical chains of certificatesultimately end with a master organisation at the top of the hierarchicaltree which has a self-signed certificate. This means that the public keyof the self-signed certificate must be obtained by means outside thepublic key infrastructure system. Such means outside the system mustinclude a “witnessable event”, to initiate (or, in computing jargon,“bootstrap”) the electronic infrastructure.

[0018] A means by which users can obtain the public key certificatesthey need, and be sure that those certificates are valid, is known as apublic key infrastructure (PKI). A traditional PKI includes aRegistration Authority (RA) to approve the issue of public keycertificates, a Certificate Authority (CA) to issue those certificates,and a Directory to store them.

[0019] An RA represents the organisation, processes, procedures andsystems that approve, create, renew, suspend or revoke unique key pairs.The RA is responsible for ensuring the uniqueness of the key pair withinits name space and—depending upon how the RA is implemented—validatingthat the recipient of key pair (a person, application, server, hardwaredevice, or file) is authorised to perform the privileges associated withit. This privilege validation could alternatively be performed by aCertificate Authority (see below). The RA can be managed internally oroutsourced through a growing number of service providers.

[0020] A CA represents the organisation, processes, procedures andsystems that control the issuance, renewal, suspension and revocation ofdigital certificates based on public keys approved by the registrationauthority. It may also be responsible for maintaining and publishing alist of the user community through its underlying directory structure.Like the RA, the CA can be outsourced as a service, but many enterprisesprefer to manage both the CA and RA services internally, integratingthem with other related administration processes such as human resourcemanagement.

[0021] Known PKI systems include the SET (Secure ElectronicTransactions) system for credit card transactions in which a PKI treehierarchy has a master SET root at the top of the hierarchy which has aself-signed public key. A lower level of the hierarchy is the brand ofcredit card. A lower level still is the banks issuing the credit cardsand the lowest level of the hierarchy is the consumer.

[0022] A consumer can obtain a root public key from his bank, forexample by visiting a branch of the bank and obtaining the bank's rootCD-ROM which includes the bank's self-signed digital certificate. Theconsumer trusts the authenticity of the root public key obtained fromthe bank. However, the consumer has no means of authenticating a publickey of any other node of the tree hierarchy.

[0023] The only “global” root public key available in the hierarchy thatcan authenticate all the other nodes in the tree hierarchy is that ofthe master SET root. If the public key is obtained for the master SETroot by the consumer, the consumer can obtain certificates certifyingthe public keys of all other nodes in the hierarchy.

[0024] Known PKI hierarchies of this nature have the disadvantage thatthe user may not trust the master global root. Trust in this context isdefined as knowing the identity of a party and having a record ofperformance of the party. Such trust can be passed between parties, if atrusted party recommends another party.

[0025] It is an aim of the present invention to enable a user to choosea root from which to obtain a root public key from any node in a PKI andto enable the user to use the root public key as a global root key toobtain a chain of certificates along a path to any other node in thePKI. This enables the user to choose an entity for its global root whichit trusts.

SUMMARY OF THE INVENTION

[0026] According to a first aspect of the present invention there isprovided a method for key certification in a public key infrastructure,the public key infrastructure having a network formed of a plurality ofnodes, each node having a private and public key pair, the nodes beingeither or both a certifying node and a certified node, a certifying nodeproviding a digital certificate making reference to the public key of acertified node and the digital certificate being signed by the privatekey of the certifying node, the method comprising: providing a rootpublic key for a user, the root public key being at a any node in thenetwork chosen by the user, and providing a chain of digitalcertificates from the node with the root public key across the nodenetwork to any other node.

[0027] A root public key may be a public key obtained by a user by meansoutside the public key infrastructure. Such means may include awitnessable event or may itself rely on a means including a witnessableevent.

[0028] A chain of digital certificates may be a sequence of nodes with acertificate for each adjacent pair of nodes, where the first node of apair is a certifying node and the second node of a pair is a certifiednode.

[0029] A node may have a computer interface for any one of a user, oneor more individuals, one or more individuals in a role, corporations,organisations, computer applications, automated machines, or any otherentity.

[0030] The node network may be a hierarchical network and a node mayprovide a digital certificate for a node below it, above it or at thesame level as it on a different branch in the hierarchical network. Achain of digital certificates may lead up, down and/or across a nodenetwork.

[0031] A digital certificate may include information relating to acertified node including a distinguished name for the certified node andits public key, the digital certificate being signed with the certifyingnode's private key. The digital certificate may be signed by forming adigest of the information in the certificate and signing the digest withthe certifying node's private key. The digital certificate may alsocontain one or more of the following information: a certificate number,a digest function, an encryption algorithm, the name of the certifyingnode, an address of the certifying node, an expiry date of the certifiednode's public key, any other data item.

[0032] According to a second aspect of the present invention there isprovided a system for key certification in a public key infrastructure,the public key infrastructure having a network formed of a plurality ofnodes, each node having a private and public key pair, the nodes beingeither or both a certifying node and a certified node, a certifying nodeproviding a digital certificate making reference to the public key of acertified node and the digital certificate being signed by the privatekey of the certifying node, the system comprising: a root public key fora user, the root public key being at a any node in the network chosen bythe user, and a chain of digital certificates from the node with theroot public key across the node network to any other node.

[0033] A root public key may be a public key obtained by a user by meansoutside the public key infrastructure.

[0034] A chain of digital certificates may be a sequence of nodes with acertificate for each adjacent pair of nodes, where the first node of apair is a certifying node and the second node of a pair is a certifiednode.

[0035] A node may have a computer interface for any one of a user, oneor more individuals, one or more individuals in a role, corporations,organisations, computer applications, automated machines, or any otherentity.

[0036] The node network may be a hierarchical network and a node mayprovide a digital certificate for a node below it, above it or at thesame level as it on a different branch in the hierarchical network. Achain of digital certificates may lead up, down and/or across a nodenetwork.

[0037] A digital certificate may include information relating to acertified node including a distinguished name for the certified node andits public key, the digital certificate being signed with the certifyingnode's private key. The digital certificate may be signed by forming adigest of the information in the certificate and signing the digest withthe certifying node's private key. The digital certificate may alsocontain one or more of the following information: a certificate number,a digest function, an encryption algorithm, the name of the certifyingnode, an address of the certifying node, an expiry date of the certifiednode's public key, any other data item.

[0038] According to a third aspect of the present invention there isprovided a computer program product stored on a computer readablestorage medium for key certification in a public key infrastructure, thepublic key infrastructure having a network formed of a plurality ofnodes, each node having a private and public key pair, the nodes beingeither or both a certifying node and a certified node, a certifying nodeproviding a digital certificate making reference to the public key of acertified node and the digital certificate being signed by the privatekey of the certifying node, comprising computer readable program codemeans for performing the steps of: providing a root public key for auser, the root public key being at a any node in the network chosen bythe user, and providing a chain of digital certificates from the nodewith the root public key across the node network to any other node.

BRIEF DESCRIPTION OF THE DRAWINGS

[0039] A preferred embodiment of the invention will now be described indetail by way of example only with reference to the following drawings:

[0040]FIG. 1A is a diagram of a conventional encryption procedure;

[0041]FIG. 1B is a diagram of a conventional signing procedure;

[0042]FIG. 2A is a diagram of a digital certificate certifying a publickey;

[0043]FIG. 2B is a diagram of a certificate chain;

[0044]FIG. 3 is a diagram of a public key infrastructure with acertificate supplier hierarchy;

[0045]FIG. 4 is a diagram of a public key infrastructure showing a keycertification in accordance with the present invention; and

[0046]FIG. 5 is a diagram of a certificate chain including reversecertificates in accordance with the present invention.

DETAILED DESCRIPTION

[0047] Referring to FIG. 1A, the known method of sending a message usingpublic key cryptography is illustrated. Public key pairs can be used tosign and scramble a message.

[0048] User A wishes to send a message 101 to user B. User A signs 102the message 101 by using A's private key. This encryption enables therecipient to verify that the message 101 has come from user A who is theonly user to know user A's private key. This results in a set of data104 formed by encrypting the original message 101 into a signature 103.

[0049] The set of data 104 is then scrambled 105 in order to keep themessage confidential. This scrambling 105 is carried out by user Aencrypting the set of data 104 with user B's public key. This ensuresthat only user B will be able to unscramble the set of data 104. Thisresults in a set of data 106 formed of an encryption 107 of thesignature 103 which includes the message 101. The set of data 106 istransmitted to user B.

[0050] User B carries out the reverse process. User B unscrambles 108the set of data 106 by decrypting the data 106 using user B's privatekey. User B then has the set of data 104 in the form of the signature103 and the message 101. User B can verify that the message 101 camefrom user A by decrypting the set of data 104 using user A's public key.User B then has the message 101 which only user B could have unscrambledwith the reassurance that the message 101 did come from user A.

[0051]FIG. 1B illustrates the known method of signing using a public keycryptography system. User A wishes to send a message 101 to user B. UserA uses a hash function 110 to obtain a digest 111 of the message 101.The digest 111 is then encrypted 112 using user A's private key toobtain a signature 114. User A sends the message 101 and the signature114 to user B.

[0052] User B applies the same hash function 110 to the message 101 ithas received to obtain a digest 115. User B also decrypts 116 thesignature 114 it has received using user A's public key. The decryptedsignature is the digest 111 made by user A. The digest 111 obtained bydecrypting the signature is compared 119 to the digest 115 made by therecipient. If the two digests are the same, the message 101 has beenverified by the signature.

[0053] In order for the above methods of public key cryptography towork, users' public keys are available to all participants in theinfrastructure. The level of availability may vary: for example, auser's public key may be disclosed to selected parties directly by theuser or a user's public key may be published in a directory. The publickey needs to be trusted. It is possible that an impostor could publish apublic key stating that it is the public key of another party in orderto pose as the other party and receive and send fraudulent messages.

[0054] To verify that a public key is in fact the public key of a givenuser, a certificate for the public key is issued by a certifying source.The certificate is of the form of a digital certificate which securesdigital information within the certificate by means of a digitalsignature using the certifying source's private key.

[0055] Through the certificate, the certifying source is providing astatement to the party relying on the information in the certificatethat it is genuine. It is the relying party that must assess the extentto which it should trust this statement.

[0056] Certificates may be created for different purposes and may beissued using different practices and procedures. These processes aretermed the Certificate Policy. One of the most widespread certificatestandards is X.509, which defines the certificate policy as “a named setof rules that indicates the applicability of a certificate to aparticular community and/or class of application with common securityrequirements”. The certificate policy is the heart of any PKI scheme; itis on the policy that users will rely.

[0057]FIG. 2A illustrates an example format for a certificate. Thecertificate 200 includes technical information 201 that may include acertificate number 202, the function 203 used to digest the signature,the encryption algorithm 204 used, etc. The certificate 200 alsoincludes information 205 regarding the certifying source issuing thecertificate 200. For example, the certifying source may be a CertificateAuthority (CA). The information 205 may also include the name of thecertifying source 206, an IP address 207 of the directory held by thecertifying source, etc.

[0058] The certificate 200 also includes subject information 208 for theentity whose public key is being certified. The subject information 208may include a distinguished name 209 of the subject for identifying theentity, the entity's public key 210, an expiry date of the public key211, and any other information.

[0059] The information 201, 205, 208 is digested 212 and signed 213 bythe certifying source using the certifying source's private keyresulting in an authentication block 214.

[0060] The information in the certificate is clear text and available tobe read by any party. However, if the information is to be relied upon,the authentication block 214 must be verified by decrypting thesignature digest as explained in relation to FIG. 1B using thecertifying source's public key.

[0061] If a relying party already knows and has verification of thecertifying source's public key, this is sufficient for the relying partyto rely on and be confident in the use of the entity's public key.

[0062] However, if the relying party does not have knowledge of thecertifying source's public key, a certificate certifying the certifyingsource's public key is also needed. This can result in a chain ofcertificates.

[0063]FIG. 2B shows a known example of a certificate chain. A user 220wishes to verify a public key of another entity 221 with which the userwishes to communicate and to do business. The entity 221 has acertificate 224 certified by his bank 222.

[0064] The entity's certificate 224 includes the information of theentity's public key 227 which the user 220 can read. The user 220 canverify the public key 227 by checking the authentication block 228 inthe certificate 224. The authentication block 228 is signed using theprivate key of the bank 222.

[0065] The user 220 needs to obtain the bank's public key 229 which canthen be used to check 234 the authentication block 228 of the entity'scertificate 224. The bank 222 in turn has a certificate 225 providingthe bank's public key 229 and an authentication block 230 signed by ahigher level authority 223 using the private key of the higher levelauthority 223.

[0066] The higher level authority 223 is an authority which the user 220knows and the user 220 has previously obtained, by means outside thepublic key infrastructure (such as a CD-ROM), the higher levelauthority's self-signed certificate 226. The self-signed certificate 226provides the public key 231 of the higher level authority 223 and has anauthentication block 232 signed using the private key corresponding tothe public key 231.

[0067] In this way, the user 220 can use the chain of certificatesstarting from the self-signed certificate 226 to verify 233 the publickey 227 of the entity 221. Then authentication block 232 of theself-signed certificate 226 confirms 236 the public key 231 of thehigher level authority 223. The public key 231 of the higher levelauthority 223 is used to decrypt 235 the authentication block 230 of thebank 222 and to confirm the public key 229 of the bank 222. The publickey 229 of the bank 222 is used to decrypt 234 the authentication block228 of the entity 221 and to confirm the public key 227 of the entity221 for use by the user 220.

[0068]FIG. 3 shows a known hierarchy of certificate sources shown asnodes. A bottom level certificate holder 301 in the hierarchy 300 canbe, for example, a consumer, an employee, a natural person or a group ofpeople, etc. The bottom level certificate holder 301 has its certificateissued by a trusted authority 302, for example, a bank for the consumeror a company for the employee.

[0069] The trusted authority 302 itself has a certificate issued by ahigher body 303 referred to in the figure as a “level 2” trustedauthority which could be, for example, a bank regulating body.

[0070] The level 2 trusted authorities 303 have certificates issued by acentralised body 304 referred to in the figure as a “level 1” trustedauthority which, in this example, is the highest level of trustedauthority in the hierarchy 300. As the highest level of the hierarchy,the centralised body 304 has a “self-signed certificate”. This meansthat the public key of the centralised body 304 must be obtained bymeans outside the system and can be verified by the self-signedcertificate of the centralised body 304.

[0071] A self-signed certificate is merely an example of a way ofrepresenting a root key—it is convenient in computer processing since itcan mark the end of a certificate chain. Any other representation couldbe used instead.

[0072] The centralised body 304 has the only “global root key” of thehierarchy because only from this node can the public keys of all theother nodes be certified. The arrows between the nodes show thedirection in which the certification of the public key is provided. Allthe nodes at the start of the arrows are “certifying nodes” and all thenodes at the ends of the arrows below another node are “certifiednodes”. This is referred to as the “centralised model”.

[0073] A root key can be obtained by a user at a node in the hierarchy.For example, a consumer 301 can go to a branch of his bank 302 andobtain a CD-ROM containing the banks public key in the form of aself-signed certificate. The consumer 301 will trust the public key hehas obtained and no further certificate chain is needed. However, theconsumer 301 cannot verify the public key of any other node in thehierarchy above the bank 302 or in a different branch of the hierarchywithout obtaining and using the level 1 public key—even if the consumerhas experience to justify trusting it.

[0074] At each level of the hierarchy 300, each trusted authorityincludes the roles of a Certificate Authority (CA) and RegistrationAuthority (RA) authenticating the identity of the next lower level inthe hierarchy. At each level it is the responsibility of the certificateissuer to ensure the authenticity of the holder.

[0075] It is also known for a level 1 trusted authority to cross-certifyanother level 1 trusted authority if a separate hierarchy therebylinking users of hierarchies stemming from different centralised bodies.

[0076] Peer level trusted authorities can also cross-certify each other.This is referred to as the “correspondent model” and is based on theidentification by two peer level certificate issuers (trustedauthorities) that they have certificate policies that are equal. Bycross-certifying their respective policies, one to the other,certificates issued by either authority can be treated as if they werealso in the other scheme.

[0077] In the method and system of the present invention, reversecertification can be practised. A lower level node can provide acertificate for a public key of a higher level node. Such a certificatewill be of the form shown in FIG. 2A with the information 205 relatingto the certifying source and the information 208 relating to thecertified subject and the certificate signed with the private key of thecertifying source.

[0078] Referring to FIG. 4, a hierarchy of certificate source nodes isshown in accordance with the described method and system. A similarhierarchy 400 is shown to that of FIG. 3 with four levels of nodes 401,402, 403, 404 starting from the lowest 401 to the highest level 404 inthe hierarchy 400.

[0079] The double-headed arrows 405 illustrate certification of thenodes in both directions. Each one of an adjacent pair of nodes providesa certificate for the other node of the pair. The adjacent nodes canalso be on the same level of the hierarchy.

[0080] Any node may be chosen by a user 406 to be its root node 407 andthe user obtains the public key for that node 407. The root node 407 isa global root node as there is a path from it to any other node in thehierarchy 400.

[0081] For example, if the consumer 406 obtains the CD-ROM with theself-signed certificate for the bank 407 and extracts the bank's publickey, the bank 407 is the consumer's chosen root node. There is a pathfrom the bank 407 to any other node in the PKI and the bank 407 istherefore the global root for the consumer 406.

[0082] If the consumer 406 wishes to carry out a transaction with anentity “X” 408 in the hierarchy 400, the consumer 406 will need to knowand have verification of the public key of entity “X” 408. The consumer406 trusts the bank 407 and has a trusted copy of the bank's public key.A path 409 (shown in dashed lines) can be followed from the bank'spublic key along a chain of certificates in order to verify the publickey of entity “X” 408.

[0083] A root node could issue certificates to every other node in a PKInetwork although this may be unnecessary. As another possible procedure,a first node could issue a certificate back to any second node issuing acertificate for the first node. This will ensure that the PKI grows withcertificates between nodes in both directions.

[0084] Certificate chains across a PKI form a path between nodes. Thenodes form a web which is can be navigated in both directions betweennodes.

[0085]FIG. 5 shows a path through a hierarchy connecting nodes 502, 503,504 and a user 501. Certificates 505 are provided at each node 502, 503,504 certifying the adjacent node in both directions.

[0086] In summary, in conventional PKI systems, if a trusted authorityhas a root key, then anyone who knows that root key can use it foridentifying the schemes it administers and, via the schemes, the schememembers. If someone claims to be a member of a particular scheme, andsends a certificate issued by that scheme, that certificate can be usedfor identification and authentication:

[0087] The method of identification and authentication is as follows:

[0088] Obtain the scheme's certificate—which is signed by the trustedauthority.

[0089] Check that neither the scheme certificate nor the membercertificate has been revoked.

[0090] Use the trusted authority root key to check the schemecertificate. Identification of the scheme is complete. A user can beconfident that the scheme exists and that he has its public key.

[0091] The scheme public key is used to check the member certificate.Identification of the member is now complete. A user can be confidentthat the member exists and that he has its public key.

[0092] The scheme member has not yet been authenticated. Anyone mayobtain a copy of his certificate, so it still need to be checked thatthe sender is indeed the scheme member himself. Accordingly, a randomchallenge is sent by the user to the sender; he encrypts it with hisprivate key; and the user decrypts it with the public key from thecertificate. If that gets the user back to the original challenge, thenthe sender has been authenticated as the certificate holder.

[0093] This process—which is carried out automatically by a computer assoon as connection is made—depends upon the user's confidence in thetrusted authority's root key. Obviously, a responsible trusted authorityis going to carry out its business so that its root key is reliable, andso that this process rarely, if ever, goes wrong. But the trustedauthority is unlikely to be willing to accept that it is liable withoutprior agreement. It may have liability because of legislation in thecountry where it is based, or it may be willing to accept liability aspart of a contractual agreement.

[0094] The problem with a traditional PKI is that there is nocontractual agreement between a trusted authority and most users of itsroot key. Only those scheme members to whom it has issued a certificatehave a contract with it, not the members of other schemes who wish toauthenticate its members.

[0095] What is needed is for an entity to issue a user with a “globalroot key” that will authenticate all other trusted authorities andschemes the user might need to deal with, and who will accept liabilityif that authentication is wrong.

[0096] One way of doing this—in the centralised model shown in FIG.2B—would be for the user to use the centralised body's root key as itsglobal root key. If the user establishes a contractual relationship withthe centralised body, then it can use that key to identify any member ofany scheme in any trusted authority network that is part of thehierarchy 200 under the centralised body. The user knows that it shallbe indemnified by the centralised body if anything goes wrong.

[0097] A very important aspect of the described method is that itdoesn't have to be a centralised body at the highest level of ahierarchy that supplies the global root key. As long as the user canbuild a chain of certificates from the global root key it is using tothe certificate the user wishes to validate, and the issuer of theuser's global root key agrees to accept liability, then the user can usethe hierarchy network with confidence.

[0098] As a second way of doing this, in the correspondent model, if thecentralised body arranges a common liability arrangement among itsmember level 2 trusted authorities then the user can use the root key ofany level 2 trusted authority as its global root key. The user's level 2trusted authority authorises the other level 2 trusted authorities,which authorise their schemes, which authorise the scheme members—andthe user's protection is assured.

[0099] Even this is not the most devolved arrangement. In particular,the user might wish to have the issuer of its global root key based inits country of residence. That way, any contract is in one jurisdictionand one language. It might be a scheme trusted authority that—as well ashaving a certificate issued by the level 2 trusted authority—also issuesa certificate for the level 2 trusted authority. This “certifying up thehierarchy” means that the user can then use the rest of the certificatenetwork. Or it might be a third party who chooses to set up such abusiness and enters into agreements with the user and with thecentralised body for downstream liability.

[0100] The system is very flexible. Everyone has a personal global rootkey—a root key issued by an organisation which is under contract toprovide reliability and liability. There does not need to be a universalglobal root key that everyone uses, established in a jurisdiction overwhich nobody has a choice. The essence is that the centralised bodyshould provide a structure in which maximum choice is possible.

[0101] The present invention is typically implemented as a computerprogram product, comprising a set of program instructions forcontrolling a computer or similar device. These instructions can besupplied preloaded into a system or recorded on a storage medium such asa CD-ROM, or made available for downloading over a network such as theInternet or a mobile telephone network.

[0102] Modifications and improvements can be made to the foregoingwithout departing from the scope of the present invention.

1. A method for key certification in a public key infrastructure, thepublic key infrastructure having a network formed of a plurality ofnodes, each node having a private and public key pair, the nodes beingeither or both a certifying node and a certified node, a certifying nodeproviding a digital certificate making reference to the public key of acertified node and the digital certificate being signed by the privatekey of the certifying node, the method comprising: providing a rootpublic key for a user, the root public key being at a any node in thenetwork chosen by the user; and providing a chain of digitalcertificates from the node with the root public key across the nodenetwork to any other node.
 2. A method as claimed in claim 1, wherein aroot public key is a public key obtained by a user by means outside thepublic key infrastructure.
 3. A method as claimed in claim 1, wherein achain of digital certificates is a sequence of nodes with a certificatefor each adjacent pair of nodes, where the first node of a pair is acertifying node and the second node of a pair is a certified node.
 4. Amethod as claimed in claim 1, wherein a node has a computer interfacefor any one of a user, one or more individuals, one or more individualsin a role, corporations, organisations, computer applications, orautomated machines.
 5. A method as claimed in claim 1, wherein the nodenetwork is a hierarchical network.
 6. A method as claimed in claim 5,wherein a node can provide a digital certificate for a node below it inthe hierarchical network.
 7. A method as claimed in claim 5, wherein anode can provide a digital certificate for a node above it in thehierarchical network.
 8. A method as claimed in claim 5, wherein a nodecan provide a digital certificate for a node at the same level as it ona different branch in the hierarchical network.
 9. A method as claimedin claim 1, wherein a chain of digital certificates can lead up, downand/or across a node network.
 10. A method as claimed in claim 1,wherein a digital certificate includes information relating to acertified node including a distinguished name for the certified node andits public key, the digital certificate being signed with the certifyingnode's private key.
 11. A method as claimed in claim 10, wherein thedigital certificate is signed by forming a digest of the information inthe certificate and signing the digest with the certifying node'sprivate key.
 12. A method as claimed in claim 10, wherein the digitalcertificate also contains one or more of the following information: acertificate number, a digest function, an encryption algorithm, a nameof the certifying node, an address of the certifying node, and an expirydate of the certified node's public key.
 13. A system for keycertification in a public key infrastructure, the public keyinfrastructure having a network formed of a plurality of nodes, eachnode having a private and public key pair, the nodes being either orboth a certifying node and a certified node, a certifying node providinga digital certificate making reference to the public key of a certifiednode and the digital certificate being signed by the private key of thecertifying node, the system comprising: a root public key for a user,the root public key being at a any node in the network chosen by theuser; and a chain of digital certificates from the node with the rootpublic key across the node network to any other node.
 14. A system asclaimed in claim 13, wherein a root public key is a public key obtainedby a user by means outside the public key infrastructure.
 15. A systemas claimed in claim 13, wherein a chain of digital certificates is asequence of nodes with a certificate for each adjacent pair of nodes,where the first node of a pair is a certifying node and the second nodeof a pair is a certified node.
 16. A system as claimed in claim 13,wherein a node has a computer interface for any one of a user, one ormore individuals, one or more individuals in a role, corporations,organisations, computer applications, or automated machines.
 17. Asystem as claimed in claim 13, wherein the node network is ahierarchical network.
 18. A system as claimed in claim 17, wherein anode can provide a digital certificate for a node below it in thehierarchical network.
 19. A system as claimed in claim 17, wherein anode can provide a digital certificate for a node above it in thehierarchical network.
 20. A system as claimed in claim 17, wherein anode can provide a digital certificate for a node at the same level asit on a different branch in the hierarchical network.
 21. A system asclaimed in claim 13, wherein a chain of digital certificates can leadup, down and/or across a node network.
 22. A system as claimed in claim13, wherein a digital certificate includes information relating to acertified node including a distinguished name for the certified node andits public key, the digital certificate being signed with the certifyingnode's private key.
 23. A system as claimed in claim 22, wherein thedigital certificate is signed by forming a digest of the information inthe certificate and signing the digest with the certifying node'sprivate key.
 24. A system as claimed in claim 22, wherein the digitalcertificate also contains one or more of the following information: acertificate number, a digest function, an encryption algorithm, a nameof the certifying node, an address of the certifying node, and an expirydate of the certified node's public key.
 25. A computer program productstored on a computer readable storage medium for key certification in apublic key infrastructure, the public key infrastructure having anetwork formed of a plurality of nodes, each node having a private andpublic key pair, the nodes being either or both a certifying node and acertified node, a certifying node providing a digital certificate makingreference to the public key of a certified node and the digitalcertificate being signed by the private key of the certifying node,comprising computer readable program code means for performing the stepsof: providing a root public key for a user, the root public key being ata any node in the network chosen by the user; and providing a chain ofdigital certificates from the node with the root public key across thenode network to any other node.